Basic explanation

What this does: An identity can hand an application a signing key that carries a budget (a cap on the credits it may spend) or an expiry (a time after which it stops signing). From protocol version 15 such a key can no longer create or update a data contract. Those two actions are reserved for keys without limits.

Value: A budget and an expiry describe how far a key may go, one state transition at a time. A data contract is a lasting commitment of its owner, so it does not fit inside either limit. With this rule, what a limited key can do for its identity stays within what its limits describe, and wallets can tell users so without an exception for contracts.

Risks: Low to medium. This is a consensus change, gated to protocol version 15: protocol version 14 and earlier validate exactly as before, and the shipped generation of the check is not edited. An application that today uses a limited key to register or update contracts will be refused from protocol version 15 with a dedicated error and has to use a key without limits for that. The refusal is unpaid, so it costs the identity nothing.

Issue being fixed or feature implemented

Key limits (protocol version 14) bound what the state transitions signed with a key take from its identity. DataContractCreate and DataContractUpdate commit the owner beyond the transition that is signed, which is outside what a budget counts and what an expiry ends. IdentityKeyLimitsUpdate is already refused for a limited key for the same kind of reason; this adds the two contract transitions.

What was done?

• validate_state_transition_identity_signed 2 (drive-abci): runs v1 unchanged, then refuses a signing key that carries a budget or an expiry on a DataContractCreate and on a DataContractUpdate. The refusal is a signature error, so it is unpaid: the identity balance, the key budget and the identity nonce stay as they are. A key v1 already refuses (a spent budget, 20015) keeps v1's answer.
• PublicKeyWithLimitsCannotSignDataContractTransitionError, code 20018, appended to SignatureError (discriminant 18, pinned by the frozen discriminant test) and mapped in wasm-dpp.
• DRIVE_ABCI_VALIDATION_VERSIONS_V11 (protocol version 15) selects generation 2. DRIVE_ABCI_VALIDATION_VERSIONS_V10 (protocol version 14) keeps 1. Note 34 in v15.rs.
• Docs: docs/protocol/authentication-key-limits.md and the book chapter data-model/key-limits.md gain a "what a limited key may not sign" section, the versioning table row and the test list.
• One existing test (should_raise_the_budget_of_a_spent_key_so_it_can_sign_again) used a contract create signed by a limited key as its probe for "the key is usable again"; it now uses a DPNS preorder create.

Example, for an identity whose key 2 is AUTHENTICATION, CRITICAL, with totalBudget set (the same holds for a key with only expiresAt, and for a DataContractUpdate):

DataContractCreate signed by key 2

Protocol version 14:  accepted, the fee is counted against the budget
Protocol version 15:  refused, unpaid
                      PublicKeyWithLimitsCannotSignDataContractTransitionError (20018)
                      balance, key budget and identity nonce unchanged

DataContractCreate signed by key 1 (CRITICAL, no limits)

Protocol version 14:  accepted
Protocol version 15:  accepted

A contract-bound authentication key was never able to sign these transitions (ContractBoundedKeyNonBatchError, 20013), so the keys this changes anything for are unbound limited keys at CRITICAL or HIGH level.

In-place changes to shipped generations

None. validate_state_transition_identity_signed 1 is called by the new generation and is not edited.

How Has This Been Tested?

New tests in packages/rs-drive-abci/.../batch/tests/key_limits.rs (data_contracts), through process_raw_state_transitions and check_tx:

• a contract create signed by a key with a budget is refused unpaid with 20018, and the contract is not stored;
• the same for a key with only an expiry;
• a contract update signed by a key with a budget, and by one with only an expiry, is refused unpaid;
• the create is kept out of the mempool;
• a key without limits still creates and updates a contract;
• at protocol version 14 a key with limits still creates and updates a contract, and its budget goes down by what the identity paid.

Run locally:

cargo test -p drive-abci --lib -- key_limits validate_state_transition_identity_signed data_contract_create data_contract_update
cargo test -p platform-version
cargo test -p dpp --lib --features all-system_contracts,fixtures-and-mocks,validation -- signature consensus::codes
cargo clippy -p dpp -p platform-version -p drive-abci -p wasm-dpp --all-targets --locked -- --no-deps -D warnings

Breaking Changes

Consensus, from protocol version 15: a DataContractCreate or DataContractUpdate signed by an authentication key that carries a budget or an expiry is refused (20018). Protocol version 14 and earlier are unchanged. New consensus error code 20018.

Checklist:

• I have performed a self-review of my own code
• My Rust, FFI, WASM, Swift or Kotlin changes follow the coding conventions
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated relevant unit/integration/functional/e2e tests
• I have added "!" to the title and described breaking changes in the corresponding section if my code contains any
• I have made corresponding changes to the documentation if needed
• If I added or changed GroveDB structure, I described it in the area's structure.rs, regenerated grovedb-structure.json, and checked the structure viewer link posted on this pull request
• If I added or changed a system contract's document schemas, I checked the contract viewer link posted on this pull request

For repository code-owners and collaborators only

• I have assigned this pull request to a milestone

🤖 Generated with Claude Code

PR Hygiene · 264b0b9

• Bots — thepastaclaw not yet — /skip-bots proceeds without the ones not yet reported
• Self-review — post /self-reviewed
• Build running
• Approvals — you own every area touched; none needed

When every merge requirement is met, the PR Hygiene check passes. Reviewer limits do not block merging; other required GitHub checks and protections still apply.

Summary by CodeRabbit

• Behavior Changes
  • Starting with protocol version 15, keys with a budget or expiry can no longer sign data contract creation or update transitions. These transitions are rejected during signature validation, without changing the identity balance, key budget, or nonce.
  • Protocol version 14 behavior is unchanged; keys with budgets can still sign data contract transitions.
• Documentation
  • Updated protocol and key-limit documentation to describe the restrictions and validation behavior.